In some cases, software running in an electronic device contains very sensitive intellectual property where either the code or software logic or cryptographic keys embedded in the code, or both, need to be kept confidential and must be stored in encrypted form.
In addition to confidentiality, it also may be important to limit the use of the encrypted code image to only specifically authorized electronic devices. For example, the same SOC (System on a Chip) with the same boot code and same code encryption key may be used in multiple device models and even by multiple device manufacturers. Despite this, there may be encrypted software that is only authorized to be decrypted in a specific device model. Likewise, there may be encrypted software that is only authorized to be decrypted in devices that are sold to a specific network operator, regardless of device model. In yet other cases, the encrypted software should only be decrypted in a device when the corresponding end user subscribes to a specific service.
One approach that addresses the above problem divides the software image into two portions—a larger portion that is encrypted with a common key such that the encrypted larger portion is exactly the same for every device and can be easily included in each manufactured device or can be downloaded with a common code download for all devices. And there is a smaller portion of the software that is encrypted with a key that is unique to each device. A separate copy of the smaller portion of the software needs to be uniquely encrypted and later delivered to each device either in the factory or in the field, post-deployment. The smaller software portion is the more secret part of the software that can have fine authorization rules applied to it and can be delivered to the exact subset of devices that are authorized to receive that software and the corresponding services or functionality that the software enables.
One drawback to the aforementioned approach is that only a small part of the software has the fine authorization rules applied. The bulk of the software would still be available to all devices and device models that have the same global code decryption key. In some cases a manufacturer, service provider or vendor would like to keep all of their software confidential and restricted to only specific devices and would like to apply the fine authorization rules to all of their software and not just a small portion of it. Unfortunately, a scalability problem would arise if the complete software image is encrypted using this existing approach, either causing the manufacturing line to slow down or causing an unreasonably large amount of network bandwidth to be used (since a uniquely encrypted software image cannot be broadcast or multicast to all of the devices and must be resent to each device individually).
Another drawback to the existing approach is the inconvenience of having to break up a software image into two parts. It is also inconvenient because every time that the software is modified it has to be split into two portions and the portion having the fine authorization applied has to be distributed in a significantly different manner from the rest of the software. Making an update to one part of the code image without affecting the second may be challenging.